Before you build your own internal platform, run these numbers

"We'll just build it ourselves" is usually said with confidence and a rough headcount estimate. Six months later, the team that was supposed to spend two sprints on it is still maintaining it a year in, and the platform that was meant to save engineering time has become one of the things engineering time goes to.

Build isn't automatically the wrong call. Sometimes it's the right one. What's missing, more often than not, is the number teams skip before deciding, the one that only becomes visible after the decision is already locked in.

The build estimate almost never includes maintenance

Key takeaway: the initial build is the smallest part of the total cost. The bill that keeps arriving is the one nobody budgeted for.

A build proposal usually prices out the work to stand the platform up: provisioning, CI/CD wiring, environment templates, access controls. What it rarely prices out is what happens after launch. Someone has to patch it when a dependency has a security advisory. Someone has to extend it when a new team's workflow doesn't fit the original design. Someone has to be the person who understands it well enough to debug it at 11pm when it breaks.

That someone is usually a senior engineer, and the hours they spend keeping the internal platform running are hours they're not spending on the product the business actually sells. The sprint count in the original proposal was never the number that mattered. The number that matters is how many senior-engineer-hours a month this requires indefinitely, and what else those hours could be producing instead.

The cost of buying is visible. The cost of building is just harder to see

Key takeaway: both options cost money. One shows up as a line item someone has to approve. The other gets scattered across people, time, and opportunity, which is exactly why it's so easy to underestimate.

The instinct to build often comes from a fair concern: a vendor's resource-based pricing is a line item someone has to approve, while internal engineering time feels "free" because it's already on payroll. That "free" time is already being paid for, in salary, and every hour spent maintaining internal platform tooling is an hour not spent on whatever justified hiring that engineer in the first place.

Buying trades a variable, hidden cost for a fixed, visible one. That trade is worth making whenever the platform work itself isn't differentiated for the business, and for most companies, environment provisioning and standardization just aren't.

The hybrid option most teams skip

Key takeaway: build and buy aren't the only two options on the table. Buying the standardized foundation and building only the thin layer that's genuinely specific to your business often beats going all in on either extreme.

The build-versus-buy framing treats this as a binary, but most delivery models have two very different kinds of work bundled together: the plumbing that every company needs (provisioning, environment consistency, access control, rollback) and the handful of things that are genuinely specific to how this particular business ships software. The plumbing is rarely worth building. The specific part sometimes is.

A hybrid approach buys the standardized foundation from a vendor and reserves the team's engineering time for the layer on top that actually differentiates the business, a custom deployment gate tied to a proprietary compliance process, say, or an internal tool that plugs into a workflow no vendor has reason to support. That's a much smaller build than an entire internal platform, and it comes with a much smaller maintenance bill attached to it.

The real question is which pieces of what you're planning to build are actually unique to your business, and which are the same provisioning and consistency problem every other engineering org has already solved, not build or buy in the abstract.

The numbers worth running before you decide

Key takeaway: three numbers turn "build vs. buy" from a debate into a calculation.

Before committing either way, it's worth putting real figures against three questions:

1. What would the build actually take, including year two?
   Not just the initial sprint estimate, but a realistic ongoing maintenance allocation: patching, upgrades, onboarding new team members to a custom system, and handling the edge cases that show up once real teams start using it.
2. What is that engineering time worth doing instead?
   If the same senior engineers spent that time on the product roadmap, what would that be worth, in either revenue impact or the cost of not hiring an additional person to do it?
3. What does "good enough" actually cost to buy? Not the sticker price alone, but priced against the maintenance number from question one, over the same time horizon. A build that looks cheaper over one quarter often looks worse over two years.

To see the shape of the math, take an illustrative example, not a verified benchmark: three senior engineers, each spending a fifth of their time maintaining the build, a realistic ratio for a mid-sized platform. At a fully loaded cost of roughly $180,000 a year per engineer, that fifth of their time works out to about $108,000 a year, every year, before counting what those engineers weren't building instead.

Weighed against a vendor's resource-based pricing for the equivalent standardized foundation, that comparison usually looks very different from the one-time sprint estimate that got the build approved in the first place.

Run the real version of that math, using your own numbers, side by side with the two other questions, and the argument tends to settle itself. It stops being about principle and turns into a spreadsheet.

Whichever way the numbers point, build, buy, or hybrid, the standardized foundation underneath is the same thing: environments provisioned consistently, usually the part of the delivery model most worth buying rather than building, whether that's on Upsun or elsewhere.

Related read: 7 weak points in your delivery model to fix before your next audit or outage

Want a clear-eyed look at what building your own platform would really cost your team, based on your setup? Book a platform standardization review.

Frequently asked questions (FAQ)

Is it ever the right call to build an internal platform instead of buying?
Yes, when the platform work itself is genuinely differentiated for the business, or when requirements are unusual enough that no vendor solution fits without heavy customization. For most standard environment provisioning and delivery workflows, it isn't differentiated, which is why the maintenance cost rarely pays for itself.

What's the most commonly underestimated cost in a build decision?
Ongoing maintenance. Most build estimates account for the initial project timeline but not the recurring engineering hours needed to keep the platform patched, extended, and adapted to evolving team requirements.

How do you compare build cost to buy cost fairly?
Compare them over the same time horizon, typically two to three years, and include the engineering time cost of maintaining a build, not just the initial project cost. A vendor's price is visible upfront; a build's true cost only becomes visible over time.

What should a team do before deciding either way?
Put real numbers against the build estimate, including year two and year three maintenance, and compare that total against what buying would cost over the same period. The comparison usually settles the decision on its own.